Flash memory devices (or simply “flash devices”) are well known in the art. Such devices may be used by a host system for storing data in flash media, which may be of NOR or NAND type. The operation of flash memory devices is typically controlled (managed) by a microprocessor-based controller with the help of a non volatile random access memory such as ROM/NOR and, in some cases, of a volatile random access memory such as RAM, DRAM or PSRAM. The flash device and the host system communicate via a communication port in the flash device. The components of the flash device are typically housed together in a common housing.
The controller may perform read operations, write operations and erase operations on the flash media. Exemplarily, NAND flash media are typically written in units called “pages”, each of which typically includes between 512 bytes and 2048 bytes, and are typically erased in units called “blocks”, each of which typically includes between 16 and 64 pages. After a block is erased by the flash management algorithm, it is normally marked immediately with an “erase mark” and an “erase count” for that block is immediately updated by a counter (by the flash management algorithm). The erase count indicates the number of erase events performed on each block. This count is important, as too many erase operations performed on a given block lead to wear. In order to prevent too much wear of a particular block, wear-leveling algorithms are used to try and distribute the Erase operations more or less evenly among the blocks.
The erase count of a specific block can be stored in the block itself (reserved area) or in another flash area (such as in a table that stores the erase counts of all blocks in the flash memory).
If a power loss (power failure) occurs between the erase operation and the erase count update operation, the flash manager (controller) loses the erase count of the particular block, as explained below. A typical process of updating an erase count of an erased block is as follows: a) the existing erase count is read into a volatile memory (e.g. RAM); b) the erase count in the RAM is incremented by 1; and c) the new erase count is written into the erased block. A power failure may cause the loss or invalidation of the erase count at any stage of this updating process, since during the process the flash manager is typically using and relying on an intermediate erase count stored in a volatile memory. By “invalid erase count” is meant an erase count whose check sum (CRC) is incorrect (in some cases the erase count is stored with its CRC); an erase count that exceeds a maximum erase count number (“maximum erase count” being defined, e.g., by the flash memory manufacturer or by a wear leveling algorithm); or an erase count that is out of the range of the “erase count tolerance.”) Example detailed scenarios whereby an erase count may become lost or invalidated are as follows:
1. When the flash manager (using a flash management algorithm) needs to erase a block, it reads the erase count of the block to be erased from the flash media and copies it to a volatile memory (RAM or DRAM). The flash manager then erases the block, the erase count is incremented and the erase count checksum is calculated by the flash manager (which stores the erase count and the erase count checksum in the volatile memory). The flash manager then aims to write the updated erase count and the checksum into the erased block. During this time, i.e., prior to writing or during writing, if there is a power failure, the erase count and/or the checksum may be only partially written. When the flash manager reads the block erase count and tries to verify it with the checksum, it will find a mismatch.
2. Another scenario is that at least one of the erase count bits has been flipped due to the fact that the flash manager has not refreshed the block. When a block is not erased for a period of time specified by the flash manufacturer, the block's bits are flipped. Consequently, it is required that in every such period of time, every block needs to be erased in order to avoid the situation of bit flips. When such a block (that stores data and has not been erased for some time) is read by the flash algorithm and its erase count parameter bits have been flipped, the erase count will not match the checksum that is also stored in the flash. In this case the flash algorithm may consider the erase count as invalid. Another situation of invalid erase count is when the bits of the checksum have been flipped. In this case the erase count will not match the checksum and thus the erase count will be considered an invalid erase count.
Existing approaches to overcome the problem of lost or invalid erase counts include, first, marking the block whose erase count is lost/invalid as a “bad” block, i.e. one that cannot be written too, and, second, defining the block whose erase count is lost/invalid as one that has not been erased yet (count set to 0). Both of these approaches have disadvantages, the first quickly leading to too many “bad” blocks, and the second being too risky.
A typical prior art method operates as follows. In a first step, the flash manager receives a command to erase a block. Next, the flash manager checks the counter of an erasable block i. If the erase count is found, the flash manager determines the best block to erase in the memory (for example, using a wear leveling procedure, as is well known in the art). If an erase count is not found, the flash manager assigns a zero erase count to block i or marks the block as a bad block, and then proceeds to determine the best block to erase.
Accordingly, there is a widely recognized need for, and it would be highly advantageous to have, a method of updating or replacing a lost or invalid erase count of a given block of a flash memory, which would overcome the limitations of the prior art.